Proper operation of electronic circuits is always desirable and is particularly important in mission critical applications. Electronic circuits are implemented in a variety of embodiments, including but not limited to printed circuit assemblies (“PCAs”) and integrated circuits (“ICs”). Electronic circuits are typically designed using either a schematic capture tool or a Hardware Description Language (“HDL”), such as the Very High Speed integrated Circuit HDL (“VHDL”), the Verilog HDL, or the SystemVerilog Hardware Description and Verification Language (“HDVL”). The field of Electronic Design Automation (“EDA”) encompasses software tools for designing, producing, and verifying electronic circuits and devices. These software tools describe electronic circuits at various levels of abstraction, such as at the electronic component, transistor, gate, or register transfer level (“RTL”) levels. Electronic circuits described at the electronic component level may include passive and/or active discrete components, integrated circuits, and hybrid circuits. Passive discrete components may include resistors, capacitors, inductors, and diodes. Active discrete components may include transistors, diodes, and LEDs.
During the development of an electronic circuit, various procedures are often used to verify and test the proper operation of the electronic circuit. The development of an electronic circuit is typically broken up into two parts, a design phase followed by a manufacturing phase. During the design phase of an electronic circuit, “verification” is used to verify the correct design of the electronic circuit. During the subsequent manufacturing phase of the electronic circuit, “testing” of manufactured devices is used to test that the manufactured hardware is being correctly fabricated according to the earlier verified design. During both verification and testing, tests are performed on the electronic circuit. The electronic circuit being verified and tested is typically referred to as the “device under verification” (“DUV”) during the development and verification phase and the “device under test” (“DUT”) during the manufacturing and testing phase. For simplicity, the device being verified and tested will be referred to here as the “device under test”.
The device can be verified at several stages of the design process. First, the device can be verified while the electronic circuit is in the schematic/HDL design stage. Verification during this stage is typically implemented using schematic/HDL simulation. During schematic/HDL simulation verification, a simulation model of the device is created in software. The simulation model of the device is provided with various input stimulus and the output of the device is analyzed. Additionally, values of electronic signals flowing through the simulation model of the device may be monitored during verification of the simulation model of the device.
Second, a physical device can be verified after it is fabricated. It is typically more difficult to monitor values of electronic signals flowing through the physical device than to monitor values of electronic signals flowing through the simulation model of the device. The physical device typically runs faster than the simulated device, complicating the verification of the actual device. In other examples, the actual device does not run faster than the simulated device.
During both software simulation verification and actual hardware verification, specific directed tests are typically written to test for potential problems in the device under test. Directed tests are typically written by hardware designers to verify specific aspects of the design of the device under test. Directed tests are typically written to test boundary cases, such as verification of proper usage of the lowest memory address of the device under test, proper usage of the highest memory address of the device under test, and proper usage and manipulation of some alternating binary ones and zeros, such as a repeating string of the number “5” and the letter “A”.
Though directed tests are helpful in checking for specific errors, it is difficult and time consuming to develop sufficient directed tests to thoroughly verify an electronic circuit design. In addition, if the design of the electronic circuit changes, new directed tests are typically required to adequately test the revised circuit design. Typically, many variables can affect the operation of an electronic circuit. It can be difficult for designers to thoroughly test every combination of these variables using only directed tests. Directed tests can be implemented in simulation, in actual physical hardware, or in hardware emulation.
Constrained random verification is sometimes used to verify electronic circuits in addition to, or instead of, directed tests. During constrained random verification, a series of random verification tests are typically generated using a hardware architecture description of the device under test and a plurality of constraints. The plurality of constraints set boundaries on the random verification tests that are generated. The generated tests are then executed on the device under test. The generated tests are designed to vigorously verify the device under test. As with directed tests, constrained random verification can be implemented in simulation, in actual hardware, or in hardware emulation.
Ideally, constrained random verification is used in the schematic/HDL simulation environment to exhaustively verify hardware in more than simple corner cases. Budget and schedule limitations prevent some hardware developers from taking advantage of schematic/HDL simulations using constrained random verification. These schematic/HDL simulations using constrained random verification are typically costly and can sometimes take days or weeks to run, depending on the design and complexity of the hardware and tests. Thus, some developers go straight from programming in a schematic capture tool or a HDL to implementing the physical circuits, bypassing simulation based verification altogether. These developers have limited options for verification in the hardware stage and will typically write some tests in the native language of the electronic circuit. These tests are typically difficult and time consuming to write. Thus, the tests do not typically go beyond verifying corner cases.